Feature/shared resoruces #46
Closed
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thanks. I will look into this soon and come back to you. |
|
Hi @facontidavide Have you had a chance to give this a look? |
facontidavide
added a commit
that referenced
this pull request
Apr 24, 2024
|
Hi I started porting this manually. Can you check this commit and see if I have forgotten anything? |
|
also, you will notice that the registry uses weak_ptr now, that makes the auto-destruction much easier (I wonder how I didn't realize that earlier). |
|
Ok, i'll have a look over the next few days and let you know! |
facontidavide
added a commit
that referenced
this pull request
Apr 24, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Background
When dealing with really big behaviour trees in the past we have found that the loading and execution becomes quite slow. (More details can be found in this issue)
In that issue it was suggested taking a singleton approach so that only one instance was created per different service/action/publisher call. At the time we were still using bt v3.8 so implemented a solution locally. We are at the stage where we want to upgrade to bt v4.0 and use this library. When looking at the code I noticed that this is a concept that had been implemented in the RosTopicSubNode but not in the RosActionNode, RosServiceNode and RosTopicPubNode.
PR contents
I have implemented a similar approach to the RosTopicSubNode for the RosActionNode, RosServiceNode and RosTopicPubNode. Making it so that if any ros interface (publisher,subscriber,service client or action client) is called from multiple places in a tree it will use the same instance.
I also created a service server (simple adding two ints together) and examples to test the service client and publisher.
I hoping that you find this functionality useful and others will benefit. More than happy for suggestions if there is a better way to implement this functionality.
To test
To test and prove this i placed a log which displays the hex value of the pointer. And in the tree had 2 instances of the same class, the pointer should match. And then if you had 2 instances of a publisher (for example) but different topic_names then two instances of the base class would be made and the log would show a different pointer.
RCLCPP_INFO(rclcpp::get_logger("test"), "%s, publisher pointer: %p", name().c_str(), reinterpret_cast<void*>(pub_instance_->publisher_.get()));I look forward to your feedback :)